Systems and methods for injecting an exception into a target thread

ABSTRACT

A fault or an exception is injected into a target thread. Instructions are processed and a target thread is recognized. As a result, an asynchronous procedure call is queued. The asynchronous procedure call is run on the target thread and the context of the target thread is modified. The target thread is executed in the modified context and an exception is raised in the target thread as a result of the modified context. The exception is handled and processing of the instruction continues.

FIELD OF THE INVENTION

[0001] The present invention is directed generally to the field ofcomputing. More particularly, the invention is directed to systems andmethods for injecting a fault or an exception into a target thread.

BACKGROUND OF THE INVENTION

[0002] Infinite loops and deadlocks are reasons that programs andoperating systems (OSs) “get stuck” or “hang”. It is an especiallypervasive and difficult problem when an OS or application is using thirdparty components. In this manner, when third party code is run and actsas part of a program or operating system, then infinite loops in thethird party code can “hang” the program or operating system. Typically,when running the third party components, the host has little control orinput over the source code of the component and therefore this thirdparty component may be considered “untrusted”. In this regard, thesecomponents perform intermittently, behaving normally in mostcircumstances and only occasionally causing a problem to the host.

[0003] Exceptions are errors or abnormal situations that occur duringthe processing of instructions. Typically, such exceptions cause adeviation from the sequence of execution. Once an exception is raised,typically, an exception handler processes the exception. An exceptionhandler is a set of instructions or routines that is invoked when anexception of the appropriate type occurs.

[0004] Today it is possible for an exception to be raised in a processthread; however, exceptions can only be raised within the thread as aside effect of something that particular thread does. For example, athread can try to access memory to which it does not have access andraise a memory management exception, or it can try to divide by zero andraise a division by zero exception. Currently, however, there is a needfor systems and methods for raising an exception or injecting anexception in another thread.

SUMMARY OF THE INVENTION

[0005] The present invention satisfies the aforementioned need byproviding systems and methods for injecting an exception into a targetthread In one embodiment of the invention, the target thread may be astuck or hung thread. By providing systems and methods for injectingexceptions into a target thread that is stuck, the number of “crashes”or “freezes” caused by a spinning thread can be reduced, therebyachieving greater stability of a running operating system or applicationprogram and increasing the overall user experience.

[0006] The mechanism of injecting an exception into a target threadcomprises generating a special exception into a thread of execution suchthat an effective unwinding of that thread is performed to point wherethe operating system or application program can process the failure,decide whether recovery is possible and continue execution. Such processavoids a user experienced “freeze” or “crash”.

BRIEF DESCRIPTION OF THE DRAWINGS

[0007] The foregoing summary, as well as the following detaileddescription of illustrative embodiments, is better understood when readin conjunction with the appended drawings. For the purpose ofillustrating the invention, there is shown in the drawings exemplaryconstructions of the invention; however, the invention is not limited tothe specific methods and instrumentalities disclosed. In the drawings:

[0008]FIG. 1 is a block diagram showing an exemplary computingenvironment in which aspects of the invention may be implemented;

[0009]FIG. 2 is a flowchart of an exemplary method of generating anexception in untrusted code in accordance with the present invention;

[0010]FIG. 3 shows a flowchart of an exemplary method for raising anexception in a target thread in accordance with the present invention;and

[0011]FIG. 4 is a high level block diagram showing an exemplary systemadapted to perform methods in accordance with the present invention.

DETAILED DESCRIPTION OF ILLUSTRATIVE EMBODIMENTS

[0012] Overview

[0013] The invention provides an operating system or application programwith the ability to inject an exception into a target thread. In oneembodiment of the invention, the target thread is a spinning thread. Inthis manner, the present invention provides a method for injecting anexception or fault into the spinning or stuck thread such that theoperating system or application can recover from a deadlock or loopsituation created by the stuck thread. A mechanism of “recovery” inaccordance with the present invention includes generating a specialexception into the thread of execution of an untrusted component thatcauses unwinding of the target thread to the point where the applicationor operating system can process the failure, decide whether recovery ispossible and continue execution.

[0014] By way of example, the present invention may be used to detectand recover from deadlocks or infinite loops caused by a stuck threadduring a hardware device failure, such as those that may occur indisplay drivers. In this manner, the display driver containing a stuckthread may spin in a busy loop waiting on a hardware bit to changestate, or if the hardware state change never occurs, the software mayspin forever. By providing a mechanism for injecting an exception into atarget thread—in this case a stuck thread—the thread can be unwound andan exception handler can determine how to handle the hung or stuckthread.

[0015] The detailed description which follows is represented largely interms of processes and symbolic representations of operations byconventional computer. The processes and operations performed by thecomputer include the manipulation of signals by a processor and themaintenance of these signals within data sets or data structuresresident in one or more memory storage devices. These symbolicrepresentations are the means used by those skilled in the art ofcomputer programming and computer construction to most effectivelyconvey teachings and discoveries to others skilled in the art. For thepurposes of this discussion, a process is generally conceived to be asequence of computer-executed steps leading to a desired result. Thesesteps generally require physical manipulations of physical quantities.Usually, though not necessarily, these quantities take the form ofelectrical, magnetic, or optical signals capable of being stored,transferred, combined, compared, or otherwise manipulated. It isconventional for those skilled in the art to refer to representations ofthese signals as bits, bytes, words, information, elements, symbols,nodes, frames, samples, data, entries, objects, images, files or thelike. It should be kept in mind, however, that these and similar termsare associated with appropriate physical quantities for computeroperations, and that these terms are merely conventional labels appliedto physical quantities that exist within and during operation of thecomputer.

[0016] Exemplary Computing Environment

[0017]FIG. 1 illustrates an example of a suitable computing systemenvironment 100 in which the invention may be implemented. The computingsystem environment 100 is only one example of a suitable computingenvironment and is not intended to suggest any limitation as to thescope of use or functionality of the invention. Neither should thecomputing environment 100 be interpreted as having any dependency orrequirement relating to any one or combination of components illustratedin the exemplary operating environment 100.

[0018] The invention is operational with numerous other general purposeor special purpose computing system environments or configurations.Examples of well known computing systems, environments, and/orconfigurations that may be suitable for use with the invention include,but are not limited to, personal computers, server computers, hand-heldor laptop devices, multiprocessor systems, microprocessor-based systems,set top boxes, programmable consumer electronics, network PCs,minicomputers, mainframe computers, distributed computing environmentsthat include any of the above systems or devices, and the like.

[0019] The invention may be described in the general context ofcomputer-executable instructions, such as program modules, beingexecuted by a computer. Generally, program modules include routines,programs, objects, components, data structures, etc. that performparticular tasks or implement particular abstract data types. Theinvention may also be practiced in distributed computing environmentswhere tasks are performed by remote processing devices that are linkedthrough a communications network or other data transmission medium. In adistributed computing environment, program modules and other data may belocated in both local and remote computer storage media including memorystorage devices.

[0020] With reference to FIG. 1, an exemplary system for implementingthe invention includes a general purpose computing device in the form ofa computer 110. Components of computer 110 may include, but are notlimited to, a processing unit 120, a system memory 130, and a system bus121 that couples various system components including the system memoryto the processing unit 120. The system bus 121 may be any of severaltypes of bus structures including a memory bus or memory controller, aperipheral bus, and a local bus using any of a variety of busarchitectures. By way of example, and not limitation, such architecturesinclude Industry Standard Architecture (ISA) bus, Micro ChannelArchitecture (MCA) bus, Enhanced ISA (EISA) bus, Video ElectronicsStandards Association (VESA) local bus, and Peripheral ComponentInterconnect (PCI) bus (also known as Mezzanine bus).

[0021] Computer 110 typically includes a variety of computer readablemedia. Computer readable media can be any available media that can beaccessed by computer 110 and includes both volatile and non-volatilemedia, removable and non-removable media. By way of example, and notlimitation, computer readable media may comprise computer storage mediaand communication media. Computer storage media includes both volatileand non-volatile, removable and non-removable media implemented in anymethod or technology for storage of information such as computerreadable instructions, data structures, program modules or other data.Computer storage media includes, but is not limited to, RAM, ROM,EEPROM, flash memory or other memory technology, CD-ROM, digitalversatile disks (DVD) or other optical disk storage, magnetic cassettes,magnetic tape, magnetic disk storage or other magnetic storage devices,or any other medium which can be used to store the desired informationand which can accessed by computer 110. Communication media typicallyembodies computer readable instructions, data structures, programmodules or other data in a modulated data signal such as a carrier waveor other transport mechanism and includes any information deliverymedia. The term “modulated data signal” means a signal that has one ormore of its characteristics set or changed in such a manner as to encodeinformation in the signal. By way of example, and not limitation,communication media includes wired media such as a wired network ordirect-wired connection, and wireless media such as acoustic, RF,infrared and other wireless media. Combinations of any of the aboveshould also be included within the scope of computer readable media.

[0022] The system memory 130 includes computer storage media in the formof volatile and/or non-volatile memory such as ROM 131 and RAM 132. Abasic input/output system 133 (BIOS), containing the basic routines thathelp to transfer information between elements within computer 110, suchas during start-up, is typically stored in ROM 131. RAM 132 typicallycontains data and/or program modules that are immediately accessible toand/or presently being operated on by processing unit 120. By way ofexample, and not limitation, FIG. 1 illustrates operating system 134,application programs 135, other program modules 136, and program data137.

[0023] The computer 110 may also include other removable/non-removable,volatile/non-volatile computer storage media. By way of example only,FIG. 1 illustrates a hard disk drive 140 that reads from or writes tonon-removable, non-volatile magnetic media, a magnetic disk drive 151that reads from or writes to a removable, non-volatile magnetic disk152, and an optical disk drive 155 that reads from or writes to aremovable, non-volatile optical disk 156, such as a CD-ROM or otheroptical media. Other removable/non-removable, volatile/non-volatilecomputer storage media that can be used in the exemplary operatingenvironment include, but are not limited to, magnetic tape cassettes,flash memory cards, DVDs, digital video tape, solid state RAM, solidstate ROM, and the like. The hard disk drive 141 is typically connectedto the system bus 121 through a non-removable memory interface such asinterface 140, and magnetic disk drive 151 and optical disk drive 155are typically connected to the system bus 121 by a removable memoryinterface, such as interface 150.

[0024] The drives and their associated computer storage media, discussedabove and illustrated in FIG. 1, provide storage of computer readableinstructions, data structures, program modules and other data for thecomputer 110. In FIG. 1, for example, hard disk drive 141 is illustratedas storing operating system 144, application programs 145, other programmodules 146, and program data 147. Note that these components can eitherbe the same as or different from operating system 134, applicationprograms 135, other program modules 136, and program data 137. Operatingsystem 144, application programs 145, other program modules 146, andprogram data 147 are given different numbers here to illustrate that, ata minimum, they are different copies. A user may enter commands andinformation into the computer 110 through input devices such as akeyboard 162 and pointing device 161, commonly referred to as a mouse,trackball or touch pad. Other input devices (not shown) may include amicrophone, joystick, game pad, satellite dish, scanner, or the like.These and other input devices are often connected to the processing unit120 through a user input interface 160 that is coupled to the systembus, but may be connected by other interface and bus structures, such asa parallel port, game port or a universal serial bus (USB). A monitor191 or other type of display device is also connected to the system bus121 via an interface, such as a video interface 190. In addition to themonitor, computers may also include other peripheral output devices suchas speakers 197 and printer 196, which may be connected through anoutput peripheral interface 195.

[0025] The computer 110 may operate in a networked environment usinglogical connections to one or more remote computers, such as a remotecomputer 180. The remote computer 180 may be a personal computer, aserver, a router, a network PC, a peer device or other common networknode, and typically includes many or all of the elements described aboverelative to the computer 110, although only a memory storage device 181has been illustrated in FIG. 1. The logical connections depicted includea local area network (LAN) 171 and a wide area network (WAN) 173, butmay also include other networks. Such networking environments arecommonplace in offices, enterprise-wide computer networks, intranets andthe Internet.

[0026] When used in a LAN networking environment, the computer 110 isconnected to the LAN 171 through a network interface or adapter 170.When used in a WAN networking environment, the computer 110 typicallyincludes a modem 172 or other means for establishing communications overthe WAN 173, such as the Internet. The modem 172, which may be internalor external, may be connected to the system bus 121 via the user inputinterface 160, or other appropriate mechanism. In a networkedenvironment, program modules depicted relative to the computer 110, orportions thereof, may be stored in the remote memory storage device. Byway of example, and not limitation, FIG. 1 illustrates remoteapplication programs 185 as residing on memory device 181. It will beappreciated that the network connections shown are exemplary and othermeans of establishing a communications link between the computers may beused.

[0027] Exemplary Embodiments

[0028]FIG. 2 is a flowchart of an exemplary method of generating anexception or injecting a fault into a target thread found in untrustedcode. For example, untrusted code may be code from a third party whereinthe developers of the operating system or application do not have accessto the third party's source code. Such third party code may beconsidered “untrusted” because the developers do not know thearchitecture and/or resulting functionality of the third party code. Itis contemplated, however, that untrusted code may be any code, from anysource, for which any characteristic is unknown to the application,operating system, or the developers thereof. It is also contemplatedthat the present invention may be used to inject a fault or an exceptioninto any thread found in any code, untrusted or otherwise.

[0029] In a typical scenario, a processor is running “trusted” code orcode associated with the application or operating system. Thereafter, atsome point, a monitored section of code is entered as shown at step 200.The entry into a monitored section of code may activate monitoringsoftware to perform monitoring functions as will be described below. Thetrusted code calls untrusted code and the processor begins to executethe untrusted code, as shown at step 205. For example, in one embodimentof the present invention, the untrusted code is from a display driver ora dynamic link library. However, the untrusted code may reside elsewherewithout departing from the scope of the invention.

[0030] While the processor is executing instructions from the untrustedcode, a target thread, or one that requires an injection of a fault orexception, is recognized, as shown at step 210. In one embodiment of thepresent invention, monitoring software is used to recognize the targetthread. In this manner, the monitoring software may use a known quantityor constraint such as time, to recognize a target thread. Specifically,the monitoring software may contain a table of predetermined timescorresponding to an associated function. Then, should the time elapsedexceed the predetermined time, a trigger is activated to recognize atarget thread. Any monitoring software and any manner of recognizing atarget thread however may be used without departing from the scope ofthe present invention.

[0031] Thereafter, at step 215, an exception is raised in the targetthread. However, it is not proper to randomly inject an exception intoan arbitrary thread. Typically, a thread sets up an exception handler tohandle exceptions that might occur within the thread. Consequently, if anew exception is randomly injected into one of these threads, the threadmay not handle the exception in an appropriate way (i.e., a way thateffectively recovers from the exception). Therefore, the followingtechnique for raising an exception in a target thread is preferablyemployed in a controlled environment where the thread “knows” that anexception may be injected therein. In one embodiment, the environmentwould be controlled by having the thread perform an operation indicatingit has entered a region of code where it expects an injected exceptionmay be injected therein. However, other control methods may be usedwithout departing from the scope of the present invention.

[0032] In one embodiment of the invention, an exception is raised in atarget thread using the method as shown in FIG. 3. First, once a targetthread is recognized at step 300, an asynchronous procedure call (“APC”)is queued, as shown in step 310. An asynchronous procedure call is afunction that executes asynchronously in the context of a particularthread. Typically, when an APC is queued to a thread, the system issuesa software interrupt. APCs generated by the system are called“kernel-mode APCs” while APCs generated by an application are called“user-mode APCs.” Either kernel-mode or user-mode APCs may be usedwithout departing from the scope of the present invention.

[0033] Once the APC is queued, the APC runs on the target thread asshown at step 320. Typically, the APC runs on the target thread the nexttime the thread is scheduled. However, other scheduling schemes may beused without departing from the scope of the present invention.

[0034] Thereafter, the context of the target thread is modified as shownin step 330. The mechanics for modifying the target thread varies fromprocessor to processor. Consequently, various ways of modifying thecontext of the target thread may be used without departing from thescope of the present invention. For example, using the Intel Pentium(x86) processor architecture, the context of the target thread may bemodified by changing the instruction pointer associated with the targetthread, and making it point to a simple function that will raise anexception. In order for the stack to unwind properly (and effectivelyraise the exception in the target thread), the function shouldpreferably appear as if it was called by the target thread itself.

[0035] Once the context of the target thread is modified, the targetthread is executed in the modified context, as shown at step 340, and anexception is raised in the target thread as a result of executing thethread in the modified context, as shown in step 350.

[0036] Turning again to FIG. 2, once the exception is raised (e.g., atstep 350), an exception handler is executed at step 220. In this manner,the handler may treat the exception in a manner that properly unwindsthe stack. Once the stack is properly unwound, the monitored section ofcode is exited at step 225. In one embodiment of the invention, once themonitored section of code is exited the monitoring software isdeactivated to save processing power. The processor may continue toexecute the trusted code, as shown in step 230. In one embodiment of thepresent invention, a structured exception handler may be used.

[0037]FIG. 4 shows an exemplary system 400 for injecting an exceptioninto any target thread. System 400 includes monitoring software 410 incommunication with an operating system or application program 450 and anexception injector 460. The system may also include untrusted code 420,a resulting simulated exception 430 and an exception handler 440.

[0038] System 400 includes an operating system or applications program450 executing thereon. Operating system or application program 450 is incommunication with monitoring software 410, an exception handler 440 andan untrusted code 420. Operating system can be any operating systemwithout departing from the scope of the present invention. Likewise, anyapplication program may be used in accordance with the principles of thepresent invention without departing from the scope thereof.

[0039] At any point during the execution of the operating system orapplication program code, a call to untrusted code 420 may be performedand the untrusted code is executed. As shown, untrusted code 420 resideswithin system 400, however, untrusted code may reside elsewhere. Forexample, untrusted code may be found remotely, for example, on theInternet or in memory or a dynamic link library residing elsewhere.

[0040] As shown in FIG. 4, system 400 includes a monitoring mechanismsuch as monitoring software 410. Asynchronously to the execution of thethread running the third party code is monitoring software 410. Once theuntrusted code is executed or once the monitored section of code isentered, such software may use any methods for detecting a target threadtherein. When the monitoring software 410 decides, for whatever reason,to inject an exception into the target thread 420, it proceeds to raisean exception in the target thread. This is represented by block 430. Inone embodiment of the present invention, the method for injecting anexception into a target thread as shown in FIG. 3 may be used.

[0041] For example, the monitoring software 410 may employ a timeouttechnique that detects a target thread based on the expiration of aspecific time parameter in relation to a call to untrusted code.Consequently, if the call to the untrusted code does not return in aspecified time, an exception injector 460 triggers a special“THREAD_STUCK” exception. For example, a source sample is _try {CallTo3dParty( ) } _except(GetExceptionCode( ) == SE_THREAD_STUCK) {HandleStuckThreadException( ); }

[0042] The exception injector 460 modifies the target thread state suchthat it appears that it made a function call that raises a systemexception within the untrusted code. VOID RaiseExceptionInThread( ) {ExRaiseStatus(SE_THREAD_STUCK); }

[0043] System 400 also contains an exception handler 440 to handle theinjected exception 430. Preferably, exception handler 440 performsstructured exception handling. In structured exception handling, blocksof code are encapsulated, with each block having one or more associatedhandlers. Each handler specifies some form of filter condition on thetype of exception it handles. When an exception is raised by code in aprotected block, the set of corresponding handlers is searched in order,and the first one with a matching filter condition is executed. Otherexception handling techniques, however, may be used without departingfrom the scope of the invention.

[0044] In one embodiment of the invention, a structured exceptionhandler may be a _try/_catch envelope that surrounds calls to untrustedcode into _try/_except brackets that allows catching and handlingspecial “THREAD_STUCK” exception. When the code in block 420 continuesto run, after having the fault injected, the standard OS structuredexception handling mechanisms will kick in, and the thread will berolled back to the appropriate exception handler represented by block440. In other words, once the exception is injected into the targetthread in the untrusted code 420, the exception handling code can takeappropriate action and properly unwind the stack. Consequently,continued proper execution of the operating system 450 or applicationprogram code may continue without significant disruption to the user.

[0045] It is noted that the foregoing examples have been provided merelyfor the purpose of explanation and are in no way to be construed aslimiting of the present invention. While the invention has beendescribed with reference to various embodiments, it is understood thatthe words which have been used herein are words of description andillustration, rather than words of limitations. Further, although theinvention has been described herein with reference to particular means,materials and embodiments, the invention is not intended to be limitedto the particulars disclosed herein; rather, the invention extends toall functionally equivalent structures, methods and uses, such as arewithin the scope of the appended claims. Those skilled in the art,having the benefit of the teachings of this specification, may effectnumerous modifications thereto and changes may be made without departingfrom the scope and spirit of the invention in its aspects.

What is claimed is:
 1. A method for generating an exception in untrusted code comprising: executing untrusted code; recognizing a target thread executing in the untrusted code; raising an exception in the target thread; and executing an exception handler responsive to the exception.
 2. The method of claim 1, wherein raising an exception in the target thread comprises: queuing an asynchronous procedure call; running the asynchronous procedure call on the target thread; modifying the context of the target thread; executing the target thread in the modified context; and raising an exception in the target thread as a result of the modified context.
 3. The method of claim 1, wherein recognizing a target thread comprises recognizing a target thread using monitoring software. 4 The method of claim 2, wherein modifying the context of the target thread comprises modifying an instruction pointer for the target thread.
 5. The method of claim 1, wherein recognizing a target thread executing in the untrusted code comprises recognizing a target thread executing in a display driver.
 6. The method of claim 1, wherein recognizing a target thread executing in the untrusted code comprises recognizing a target thread executing in a dynamic link library.
 7. The method of claim 1, wherein recognizing a target thread comprises recognizing a spinning thread.
 8. The method of claim 1, wherein recognizing a target thread comprises recognizing a target thread based on a violation of a constraint.
 9. A method for raising an exception in a target thread comprising: recognizing a target thread; queuing an asynchronous procedure call; running the asynchronous procedure call on the target thread; modifying the context of the target thread; executing the target thread in the modified context; and raising an exception in the target thread as a result of the modified context.
 10. The method of claim 9, wherein recognizing a target thread comprises recognizing a target thread using monitoring software.
 11. The method of claim 9, wherein modifying the context of the target thread comprises modifying the instruction pointer for the target thread.
 12. The method of claim 9, wherein recognizing a target thread comprises recognizing a target thread executing in a display driver.
 13. The method of claim 9, wherein recognizing a target thread comprises recognizing a target thread executing in a dynamic link library.
 14. The method of claim 9, wherein recognizing a target thread comprises recognizing a spinning thread.
 15. The method of claim 9, wherein recognizing a target thread comprises recognizing a target thread based on a violation of a constraint.
 16. A computer-readable medium comprising computer-executable instructions to perform a method of generating an exception in untrusted code, the method comprising: executing untrusted code; recognizing a target thread executing in the untrusted code; raising an exception in the target thread; executing an exception handler; and executing trusted code
 17. The computer readable medium of claim 16, further comprising computer-executable instructions to perform the steps of: queuing an asynchronous procedure call; running the asynchronous procedure call on the target thread; modifying the context of the target thread; executing the target thread in the modified context; and raising an exception in the target thread as a result of the modified context.
 18. The computer readable medium of claim 16, further comprising computer-executable instructions to perform the step of: recognizing a target thread comprises recognizing a target thread using monitoring software.
 19. The computer readable medium of claim 16, wherein modifying the context of the target thread comprises modifying an instruction pointer for the target thread.
 20. The computer readable medium of claim 16, wherein recognizing a target thread executing in the untrusted code comprises recognizing a target thread executing in a display driver.
 21. The computer readable medium of claim 16, wherein recognizing a target thread executing in the untrusted code comprises recognizing a target thread executing in a dynamic link library.
 22. The computer readable medium of claim 16, wherein recognizing a target thread executing in the untrusted code comprises recognizing a spinning thread executing in the untrusted code.
 23. The computer readable medium of claim 16, wherein recognizing a target thread comprises recognizing a target thread based on a violation of a constraint.
 24. A computer readable medium comprising computer-executable instructions to perform a method of raising an exception in a target thread, the method comprising: recognizing a target thread; queuing an asynchronous procedure call; running the asynchronous procedure call on the target thread; modifying the context of the target thread; executing the target thread in the modified context; and raising an exception in the target thread as a result of the modified context.
 25. The computer readable medium of claim 24, wherein recognizing a target thread comprises recognizing a target thread using monitoring software.
 26. The computer readable medium of claim 24, wherein modifying the context of the target thread comprises modifying the instruction pointer for the target thread
 27. The computer readable medium of claim 24, wherein recognizing a target thread comprises recognizing a target thread executing in a display driver.
 28. The computer readable medium of claim 24, wherein recognizing a target thread comprises recognizing a target thread executing in a dynamic link library.
 29. The computer readable medium of claim 24, wherein recognizing a target thread comprises recognizing a spinning thread.
 30. The computer readable medium of claim 24, wherein recognizing a target thread comprises recognizing a target thread based on a violation of a constraint.
 31. A system for injecting an exception into a target thread comprising: a first module for executing trusted and untrusted code; a second module for monitoring the execution of the trusted and untrusted code and for recognizing a target thread executing therein; a third module for injecting an exception into the target thread; and a fourth module for handling the injected exception in the target thread.
 32. The system of claim 31, wherein the third module comprises a module for queuing an asynchronous procedure call, running the asynchronous procedure call on the target thread, modifying the context of the target thread, executing the target thread in the modified context, and raising an exception in the target thread as a result of the modified context.
 33. A system for injecting an exception into a target thread comprising: a storage device comprising untrusted and trusted code; a processor for executing the trusted and untrusted code from the storage device; an exception injector in communication with the processor for injecting an exception into a target thread; and an exception handler for handling the injected exception in the target thread.
 34. The system of claim 33, wherein the exception handler is a structured exception handler.
 35. The system of claim 34 further comprising: monitoring software in communication with the exception injector. 